Although the Internet has had great successes in facilitating communications between computer systems and enabling electronic commerce, the computer systems connected to the Internet have been under almost constant attack by hackers seeking to disrupt their operation. Many of the attacks seek to exploit vulnerabilities of software systems including application programs or other computer programs executing on those computer systems. Developers of software systems and administrators of computer systems of an enterprise go to great effort and expense to identify and remove vulnerabilities. Because of the complexity of software systems, however, it is virtually impossible to identify and remove all vulnerabilities before software systems are released. After a software system is released, developers can become aware of vulnerabilities in various ways. A party with no malicious intent may identify a vulnerability and may secretly notify the developer so the vulnerability can be removed before a hacker identifies and exploits it. If a hacker identifies a vulnerability first, the developer may not learn of the vulnerability until it is exploited—sometimes with disastrous consequences.
Regardless of how a developer finds out about a vulnerability, the developer typically develops and distributes to system administrators “patches” or updates to the software system that remove the vulnerability. If the vulnerability has not yet been exploited (e.g., might not be known to hackers), then a developer can design, implement, test, and distribute a patch in a disciplined way. If the vulnerability has already been widely exposed, then the developer may rush to distribute a patch without the same care that is used under normal circumstances. When patches are distributed to the administrators of the computer systems, they are responsible for scheduling and installing the patches to remove the vulnerabilities.
Unfortunately, administrators often delay the installation of patches to remove vulnerabilities for various reasons. When a patch is installed, the software system and possibly the computer system on which it is executing may need to be shut down and restarted. If the vulnerability is in a software system that is critical to the success of an enterprise, then the administrator needs to analyze the tradeoffs of keeping the software system up and running with its associated risk of being attacked and of shutting down a critical resource of the enterprise to install the patch. Some administrators may delay the installation of the patch because they fear that, because of a hasty distribution, it might not be properly tested and have unintended side effects. If the patch has an unintended side effect, then the software system, the computer system, or some other software component that is impacted by the patch may be shut down or made to fail by the patch itself. Administrators need to factor in the possibility of an unintended side effect when deciding whether to install a patch. These administrators may delay installing a patch until experience by others indicates that there are no serious unintended side effects.
Intrusion detection systems have been developed that can be used to identify whether an attempt is being made to exploit a known vulnerability that has not yet been patched. These intrusion detection systems can be used to prevent exploitations of newly discovered vulnerabilities for which patches have not yet been developed or installed. These intrusion detection systems may define a “signature” for each way a vulnerability can be exploited. For example, if a vulnerability can be exploited by sending a certain type of message with a certain attribute, then the signature for that exploitation would specify that type and attribute. When a security enforcement event occurs, such as the receipt of a message, the intrusion detection system checks its signatures to determine whether any match the security enforcement event. If so, the intrusion detection and/or prevention system may take action to prevent the exploitation, such as dropping the message.
The collection of signatures for an enterprise forms part of the security policy of that enterprise. An enterprise may have many different security policies which are collectively referred to as the security policy of the enterprise. A security policy is typically expressed as rules that each have a condition indicating when the rule is satisfied and one or more actions to be performed when the rule is satisfied. The condition of a rule may include signatures or other detection criteria. The condition, action, and exception of the rules may be specified as expressions. A rule may be semantically expressed as “IF conditions THEN actions EXCEPT exceptions.” Conditions of a rule are expressions of circumstances under which security enforcement actions of the rule are to be performed. An action is an expression of activity to be performed when the condition is satisfied. A rule may have multiple actions. An exception is an expression of when the actions may not be performed even though the condition is satisfied. A condition may be either static or dynamic. A static condition is one which refers, for example, to a hard-coded list of files. A dynamic condition is one which, for example, performs a query to determine a list of files matching a provided criterion. Security enforcement actions may include allowing a request that caused the security enforcement event, denying the request, soliciting input from a user, notifying the user, and so on. Other rule constructs are also possible. As an example, an “else” construct could be added to perform alternate actions when a condition is false. A security engine may be responsible for receiving security enforcement events and applying the rules of the security policy of the enterprise.
Security policies are typically distributed by the developers of the security policies to the administrators of enterprises for implementation on the computer systems of the enterprises. After the administrators have tested the security policy, the security policy is distributed to the computer systems of the enterprise. When the computer systems of the enterprise receive the security policies, the computer systems start enforcing the received security policies. Because an enterprise may have thousands of computer systems, it can take a considerable amount of time to distribute the security policies. In addition, because some computer systems may be offline at the time of distribution (e.g., a laptop not connected to the network or a desktop that is turned off), not all computer systems will receive the security policy. As a result, some computer systems of the enterprise may start enforcing the security policies before other computer systems. This staggered enforcement of security policies may present problems, especially when a security policy was not tested in an environment where some computer systems enforce the security policy, but others do not.
Administrators often delay distribution of security policies for many of the same reasons that they delay the distribution of patches to remove vulnerabilities. In particular, the administrators may fear that the security policies have not been properly tested (especially in the environment of the enterprise) and may have unintended side effects. If a security policy has an unintended side effect, then critical software systems of the enterprise may be adversely affected. Moreover, once a security policy is distributed to the computer systems of the enterprise, it can be difficult to retract a security policy when the unintended side effects adversely affect the critical systems.